Page history of 이콜레모 2015년 회고

2015년은 지금까지 이콜레모의 역사에서 한 가지 목표만을 끝까지 유지한 첫번째 해였다. 그만큼 이전까지의 이콜레모는 전략적으로 형편 없었다는 뜻이 되겠다. 이전에도 이콜레모가 외주를 많이 했고, 중간중간에 재미 있었던 순간도 많았지만, 총체적으로 유쾌한 경험이었다고는 할 수 없었다. 다음은 그런 고민들이 담겨 있는 글들이다.

이콜레모 외주 실패의 역사

• 일기장/2009-02-27 우리는 프로젝트의 성공을 원하지만, 고객은 프로젝트의 완료를 원한다.
• 일기장/2009-05-03 대기업의 횡포
• 일기장/2009-05-11 적당히 외주해서 돈 모은 다음에 우리 아이템 하자는 전략의 허구성
• 일기장/2009-11-04 창업 이념을 잃고 돈에 휘둘린 시간
• 일기장/2009-12-14 이젠 돈에 휘둘리지 말아야지
• 일기장/2010-05-24 갑질 고객을 미리 판별할 수 있을까?
• 일기장/2010-05-16 좋은 외주 고객에 대한 나름대로 생각해본 조건

뭐 구질구질 많지만, 요약하면 제대로 외주하는 것도 아니면서 돈에 휘둘리기는 했고, 좋은 고객을 필터링하기 위해 열심히 회고하고 분석했으나 다 소용 없었다는 이야기다. 그래서 재작년에 다시 외주를 시작할까 아니면 아예 새로운 길을 찾을까 고민을 많이 했었다. 그러다가 새로운 시스템으로 외주를 해보기로 마음을 먹었다. 그 시스템은 바로 시간제 보수 시스템이다.

시간제 보수 시스템의 배경

이 시스템을 선택하는데 영향을 주었던 것들은 이런 것들이다.

• 변호사, 세무사 등은 시간당 상담료를 받는다.
• XP에서 이야기하는 외주 프로젝트에서의 pay per use 개념
• 자신이 원하는 수준에 따라 개발 비용이 차이가 난다는 것을 알게 되면 고객도 더 합리적으로 행동하려고 하지 않을까?
• 소프트웨어 견적의 불합리성
• 프로그래머도 노동자인데 노동 가치로 돈을 받는 것이 합리적이지 않을까?
• 몇 번의 짧은 취업 경험에서 내 시장 가치가 꽤 괜찮다는 것을 알게 됨.
• 어차피 내 마음에 드는 소프트웨어를 외주에서 만들 수 없다면 그에 상응하는 돈이라도 받자.
• 지섭이에게서 배운 연봉 협상 전략 - 원하는 금액을 스스로 정하고 그 금액을 주는 회사를 만나기 전까지 타협하지 말라.
• 공인 단가대로 제대로 받을 수만 있다면 먹고 사는데는 문제 없다.

프로그래머의 수급 불균형

연봉 협상 전략은 지섭이가 자기가 원하는 연봉을 정해놓고 취업하는 과정을 보고 배운 것이다. 옆에서 지켜보니 연봉은 자기가 원하는 금액에 다소 못 미치지만 그 외의 조건들을 생각해보면 괜찮아보이는 건들이 여럿 있었는데 지섭이는 계속 거절했다. 솔직히 지섭이가 저러는 걸 보기 전까지의 나라면 저러다 영영 취직 못할까봐 겁나서 못했을 거다. 근데 이 녀석은 꿋꿋이 밀고 나가더니 결국 원하는 조건의 일자리를 찾았다. 뭐 그 뒤로 오래 일한 것 같진 않지만;;

그래서, 나도 이콜레모를 잠정 중단하고 취업을 해볼까 하던 시기에 이 전략을 채용했다. 근데 조금 더 나아갔다. 협상이 한 번 실패할 때마다 희망 연봉을 1천만원 올리기. 이렇게까지 할 수 있었던 것은 지섭이를 지켜보면서 용기를 얻게 된 것도 있고, 또 그 사이 프로그래머 수요가 더 늘어나서 공급을 크게 초과하고 있다는 사실도 눈치 챘기 때문이다. 항상 시장 원리에 당하기만 해왔던 노동자 입장이지만 시장 상황이 변하면 역으로 이용할 수 있는 것도 당연하다.

그래서 네 번 협상을 실패하고 다섯 번째에 내가 원하는 조건으로 취직을 성공했다. 나 역시 지섭이처럼 거기에 오래 머무르진 못했지만, 여튼 이 경험은 고급 프로그래머의 수급 상황에 대한 확신을 가질 수 있었다. 그래서 내가 지금도 다른 프로그래머들에게 이런 조언을 한다. 

찾는 곳이 없으면 나에게 오라. 내가 일거리를 주겠다.

소프트웨어 견적의 불합리성

이게 내가 용기를 낼 수 있었던 이유라고 한다면, pay per use의 개념은 이 시스템이 더 합리적이라고 생각하는 이유다. 아니, 반대로 소프트웨어 견적의 불합리성이라고 해도 좋겠다. 소프트웨어 프로젝트를 미리 견적을 낸다는 것 자체가 말이 안되는 개념이다. 아직 소프트웨어 개발이 얼마나 걸릴지 예측할 수 있는 프로그래머는 태어난 적이 없다.

소프트웨어 개발을 시작하기도 전에 미리 견적을 내서 비용을 고정하고 프로젝트를 하면 갑과 을은 어떻게 행동하게 될까? 갑은 최대한 작은 견적을 받아서 계약하려고 할 것이고, 을은 최대한 부풀리려고 할 것이다. 여기까지는 좋다. 시장이니까. 근데 문제는 계약한 후에 일어난다. 계약한 후에 갑의 행동은 어떻게 될까? 갑은 이미 비용이 고정되어 있으니 최대한 많은 기능을 집어넣으려고 한다. 그게 이익이라고 생각하니까. 그러면서도 이미 약속했던 기능이 안되는 사실은 참을 수 없다. 손해니까.

을은 당연히 정반대로 행동한다. 이미 받을 비용은 정해져 있으니까 최대한 적은 노동을 해주는 게 이익이므로 고객과의 협상은 늘 일의 양을 줄이는데 초점이 맞춰진다. 물론 가끔은 을의 담당자가 자기 회사의 프로그래머보다 갑을 만족시키는 것을 중요하게 생각하는 경우가 있는데, 이 경우는 을의 담당자가 갑 역할이 되고 프로그래머들이 을 역할이 되기 때문에 문제가 쉬프트되긴 해도 그대로 존재한다. 어쩌면 이게 많은 프로그래머들의 현실일 것이다. 팀장은 갑님 앞에서 예스맨이 되어 굽실거리다 회의 끝내고 와서는 프로그래머들을 몰아세우는 상황. 

이런 것 뿐만이 아니다. 예를 들어 내가 고객의 요구를 아주 멋지게 만족시켜줄 수 있는 방안이 생각났는데 이미 계약한 금액이 턱없이 모자란다. 그럼 내가 그 아이디어를 말할까? 반대로 고객이 자기도 처음에 원했던 기능 중에 하나가 이제 필요 없다는 것을 알았는데, 이거 안해도 된다고 할까? 하든 안하든 비용 지불하는 건 똑같은데? 다행히 지혜로운 고객들도 종종 있고, 그들은 그게 결과적으로 자신들에게도 이득이라는 것을 알기 때문에 필요 없는 것은 처음에 하기로 했더라도 빼자고 하는 경우가 있다. 하지만, 대부분은 이게 손해보는 느낌이 드는지, "그래도 하기로 했잖아요"하면서 끝까지 요구하는 경우가 많다. 아니면 그 대가로 다른 걸 넣어달라고 하거나.

이처럼 고정 비용 하에서는 갑과 을의 이해 관계가 상충되기 때문에 이 소프트웨어를 어떻게 하면 잘 만들어야 할까 둘이 머리를 맞대고 고민을 해야 할 중요한 회의 시간에 이 일을 뺄까 더할까로 싸우게 된다. 프로젝트가 잘 되려면 둘이 협력을 잘 해야 할 텐데 말이다. 근데, 애자일 선언의 세번째 가치가 뭐더라?

Customer collaboration over contract negotiation

나는 이걸 하고 싶은 거다. 그렇다고 해서 손해를 보면서 일할 생각은 눈꼽만큼도 없다. 그럼 답은 간단하다. 일한 만큼 돈을 받으면 된다.

일한 만큼 돈을 받으면 고객이 아무리 무리한 요구를 하더라도 그만큼 돈을 받으니까 나는 손해를 보지 않는다. 그러면 나도 열린 마음으로 고객의 문제 해결에 집중할 수 있게 된다. 근데 여기까지 해주면 내가 손해고, 저기까지 해주면 내가 이익이고 이런 생각을 해야 하는 상황이 오면 집중이 될 리 만무하다. 예전의 이콜레모는 다소 손해를 보더라도 고객에게 좋은 기능을 탑재해주는 것을 우선하기도 했는데, 그 결과는 적자는 도저히 유쾌하게 받아들일 수가 없었다.

시간제 보수 시스템을 적용한 후에 일어난 변화